Network ring topologies are gaining in popularity, particularly in Internet Protocol (IP) networks. Such networks enable carriers to offer large bandwidth to users in a cost-effective manner. In order to gain these benefits, however, IP needs appropriate support at the Media Access Control (MAC—protocol layer 2) level, to provide functions such as load balancing, protection and clock synchronization.
One solution that has been proposed to meet these needs is the Spatial Reuse Protocol (SRP), which is described by Tsiang et al., in Request for Comments (RFC) 2892 of the Internet Engineering Task Force (IETF). This document, which is available at www.ietf.org/rfc.html, is incorporated herein by reference. SRP relates to the ring network as two overlapping local area networks (LANs), identified arbitrarily as an inner ring and an outer ring. In one of the rings, communication flows clockwise, while in the other it flows counterclockwise. Each node in the ring can communicate directly with all other nodes through either of the rings, using the appropriate MAC addresses of the nodes. Spatial reuse enables different nodes to use different, non-overlapping spans of the same ring simultaneously (unlike earlier ring protocols), thus increasing the overall aggregate bandwidth that is available. SRP allows nodes to choose whether to route their packets on the inner or the outer ring, but it does not provide any method for nodes to use in deciding which ring to choose.
SRP also defines a mechanism to be used by nodes on the ring in learning the ring topology. In the topology discovery phase of network start-up, described in section 4.6 of RFC 2892, each node can send out topology packets on one or both rings. The packet hops around the ring from node to node. Each node appends to the packet its own MAC address binding and other information. Eventually the packet comes back to the originating node, which uses the information that has been appended by the other nodes to build a topology map of the ring.
There are routing protocols known in the art for choosing an optimal path from a source node to a destination node through a network when multiple paths are available. These protocols have generally been designed with mesh networks in mind, although they can also be applied to bi-directional ring networks. For example, the Open Shortest First Protocol (OSFP) is a link-state routing protocol that is used to identify and select the path that has the lowest overall “cost.” OSFP is described by Moy in RFCs 1583 and 2328 of the IETF, which are available at the above-mentioned Web address and are likewise incorporated herein by reference. This protocol enables a system administrator to assign a cost to each link in the network, so that low-cost links are the ones most likely to be selected for routing. OSFP does not specify, however, how the costs are to be determined. Moreover, since the costs are assigned statically by the system administrator, the protocol does not provide any means or basis for updating the costs automatically, while the network is running, in response to network resource constraints.
After learning the network topology and routing information, the source node must still confirm that it has sufficient resources (such as bandwidth) available to it over a desired route before it can transmit a data flow over the route. The resource requirements for a given transmission depend, inter alia, on the Quality of Service (QoS) level at which the transmission is to be sent. Typically, one of the nodes is appointed to centrally manage resource allocation among all of the nodes in the network or in a given subnet of the network. The manager may be a fixed entity, or it may be chosen from among the nodes using a suitable network management protocol. An example of such a protocol is the Subnet Bandwidth Manager (SBM) protocol, described by Yavatkar et al., in IETF RFC 2814, which is available at the above-mentioned Web address and is incorporated herein by reference. The source node requests the resources that it needs from the manager, typically using another standard protocol, such as the Resource Reservation Protocol (RSVP), described by Braden et al., in IETF RFC 2205, which is likewise available at the above-mentioned Web address and is incorporated herein by reference.